The 640 MEG Shareware Studio 2

home *** CD-ROM | disk | FTP | other *** search

/ The 640 MEG Shareware Studio 2 / The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO / door / mplus300.zip / NETINFO.DOC < prev next >

Wrap

Text File | 1993-01-06 | 32KB | 634 lines

NETINFO.DOC - set up instructions for QWK networking features of Mail Manager +Plus+. We have included three files in this package that are related to QWK networking: - MUSER.EXE is the user file editor for Mail Manager's internal users file, MAILMGR.USR. Use this to add a username, net status capability for a particular username, etc. All options on the HOST end of the line are taken care of via this utility. - MNET.EXE is the QWK->REP conversion utility for the NODE end of the line. The host does not need this utility. - SAMPLE.CFG is a sample MNET configuration file (again, for the NODE end of the line) based on what we're about to talk about. Mail Manager +Plus+ can produce MarkMail-compatible mail packets for specific usernames on your system. Said mail packets can be processed with any number of QWK network utilities from other authors such as TNET, RNET, et al, as well as Mail Manager's own MNET utility (included in this package). Therefore, Mail Manager +Plus+ network-capable mail packets can easily be used by sysops of ANY bulletin board type that has a supporting QWK network utility..! Also, the MNET utility was written to be completely generic. Therefore, nearly any sysop who has a QWK mail door capable of generating and handling network packets can use the MNET utility for their file conversion, without resorting to an external processor. QWK networking is intended as an alternative to Fido-style mail transfer. You do not need to completely reconfigure your BBS to get into QWK network mail transfer. The sysop acting as the "node" must get into some serious file conversion, however (all of which Mail Manager +Plus+, and accompanying utilities can handle for you). QWK and Fido network mail transfer do not mix well. It is strongly recommended that you keep your QWK and Fido network message bases SEPARATE FROM EACH OTHER, and do not try to transfer the same conference via both methods. A QWK-format net system is complex enough that explaining how to set it up gets rather involved, so lets take it in stages: ------------------------------------------------------------------------- PHASE I : GENERAL OVERVIEW ------------------------------------------------------------------------- The scenario works like this: You have a conference or two that you would like to share with a few other interested sysops. This means that you are acting as the "host", and the people calling in to receive this conference from you are acting as nodes. They would call up your system with a username which you have set up to have "net status". They would then load up the Mail Manager +Plus+ door, and download their mail packet: Your BBS Their BBS =========== download =========== YOURBBS.QWK ---------------> YOURBBS.QWK (downloaded from you) | Tossed into into their mail door via any of several means, depending on system. | New messages from them are extracted via any of several means, depending on system, to produce: upload | YOURBBS.REP <--------------- YOURBBS.REP | Uploaded into your mail door, and processed by your system. As you can see, it is real easy to become a "host" in this operation. All you have to do is grant the user "net status" and configure which conferences to allow the user net access to. All of the dirty work (file conversion) is done on the "node" end of the line. Now, if the REVERSE is true, (another sysop has a conference that YOU are interested in), you would do exactly the reverse. You would call their system, extract and download your QWK packet, and do the necessary conversion on your end of the line. You would then call their BBS back up, and send up any replies destined for them. Again, this would work like so: Your BBS Their BBS =========== download ============ THEIRBBS.QWK <---------------------- THEIRBBS.QWK | (use MNET util to convert to:) | YOURBBS.REP | (upload into your MAILMGR+ door. New outgoing messages are extracted into:) | YOURBBS.QWK. | (use MNET util to convert to:) | upload THEIRBBS.REP ---------------------> THEIRBBS.REP | Uploaded into their mail door, and processed. Now, you would probably imbellish this to make the call that does all of this at once (IE - Send up THEIRBBS.REP and download THEIRBBS.QWK in the same session). By the same token, the guy who is calling *YOU* (with you acting as the host) would probably do the same thing in reverse. ------------------------------------------------------------------------------ PHASE II: SETTING UP AS HOST ------------------------------------------------------------------------------ A suggestion, hint, or whatever: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Before we go into the details of how to set up a host board, we would like to suggest you consider setting up a second copy of MAILMGR+ to use for your net activities, if you have the disk space for it. You can completely isolate your net activities from your normal user activities this way, and can configure the net door for only those conferences that you wish to have available for net transfer. Both copies of the door can access the same RBBS message and user files, but they will need to be set up in separate directories, and have their own MAILMGR.USR files. It is a good idea to give this second copy of the door a different packet name from that used in your user door, so the QWK and REP packets don't get mixed up. Doing this all with one door, a net user who is also a personal user of the board will be forced to make two calls - one under his "net" name and one under his real name. With a separate copy of the door for net activities, it will not be necessary to create bogus user names for your net node callers - they can call in under their normal names, do net transfers from your net door, and still be able to do "personal" QWK/REP activity in your user door, plus carry out any other normal activities on your board all in the same call. One of the first boards to beta test the net capabilities of MMGR set up a separate door for net activity, and it has been quite satisfactory. Now on with the show ... Installing/configuring for Host Operation: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This has to be done first, before any QWK net mail transfer can take place. Let's pick a random example of how you might want to start something like this in the first place... filenames listed below for NODE and HOST are just for clarity: HOST's mail packets are named HOST.QWK, and he expects HOST.REP to be uploaded into his Mail Manager +Plus+ door. The host wants to allow a particular user to network his message area named SPECIAL. (This would be SPECIALM.DEF and SPECIALU.DEF for RBBS message and user files). The person who is to be calling in to download mail and upload replies is "JOHN DOE". On the bbs that John Doe runs, his QWK door uses mail packets named NODE.QWK and NODE.REP. (If you are NOT setting up a separate door for net use, John will need a special username to pick up his network mail, so that we can keep track of last message read and so forth without screwing up John's own "real" logon sessions to your board. You decide to give John a fake name of "NODE MAIL" for network mail purposes.) OK. With that in mind, here is what you would do: (Written for a single door setup, using a dummy name for the user. If you are going to have a separate door for net activity, the instructions are the same except you would skip steps 1 and 2, and use the user's real name) 1) Create a user name on your system of "NODE MAIL". Give him a password, and a standard security level that you would give anyone else. (He doesn't need any elevated security). Say you made his password "QWKMAIL". 2) Inform John Doe that his username and password for mail purposes is "NODE MAIL", with the password "QWKMAIL". 3) Run the MUSER.EXE utility, and add "NODE MAIL" to the file, using option 2 from the MUSER edit screen. 4) Using MUSER.EXE, set up the user's options for net access. Based on what we have discussed above, the screen would look something like this: ---> start screen capture MUSER - Utility to edit MAIL MANAGER +PLUS+ User Files. Version 3.00 Copyright (C) 1992, Newark Connections. All rights reserved. ═══════════════════════════════════════════════════════════════════════════════ A) USER: NODE MAIL RECORD: 5 ─────────────────────────────────────────────────────────────────────────────── B) Packet type: QWK L) Abort if no msgs: Yes C) Update pointer: Yes M) Ask before send: No D) Xfer protocol: Z N) Default msg select: All msgs E) Msg to ALL as pers: No O) Turbokey: On F) Display Menu: No P) Net Status: Net node G) Archive choice: ZIP Q) Net identification: NODE H) Last-on (YYMMDD): 921102 R) .MSG Date (YYMMDD): 800101 I) Send own msgs: No S) .MSG Time (HHMMSS): 000000 J) Send bulletins: No T) .MSG Length: 0 K) Send new file info: No ═══════════════════════════════════════════════════════════════════════════════ TO SELECT USER: Press , , PgUp, PgDn. (<ESC> to QUIT) OPTIONS: EDIT USER SHOWN: 1) Find User Name A-T) Edit data above 2) Add new user 4) Edit conf data 3) Purge User Records 5) Delete user ═══════════════════════════════════════════════════════════════════════════════ ---> end screen capture Most important of the above are the following options: P) Net Status = Net node Q) Net identification = NODE The other options he can set for himself the first time he logs on, or are handled automatically by the door. Net status and net identification he CANNOT set up himself, however. The net identification field is used by Mail Manager +Plus+ to keep track of which messages originally came from that "net status" user, to prevent him from receiving these same messages back in subsequent QWK packets. The identifier can be any combination of (up to 8) characters which will uniquely identify this user to your system. We suggest that a convenient identifier might be the QWK/REP base packet name used at HIS end of the line. (In our example here, the node uses NODE.REP and NODE.QWK at his end of the line, so we used NODE as the indentifier.) Once you have set these options, the last thing to do is to flag which conferences you would like him to be able to pick up. Do this by punching option 4 from the above menu (MUSER takes you there automatically when setting up a new net user). You'll get a screen that looks like this: ---> Start screen capture MUSER - Utility to edit MAIL MANAGER +PLUS+ User Files. Version 3.00 Copyright (C) 1992, Newark Connections. All rights reserved. ═══════════════════════════════════════════════════════════════════════════════ A) USER: NODE MAIL RECORD: 7 ─────────────────────────────────────────────────────────────────────────────── 1 --- 11 --- 21 --- 31 --- 41 --- 2 --- 12 --- 22 --- 32 --- 42 --- > 3 NET all-A 13 --- 23 --- 33 --- 43 --- 4 --- 14 --- 24 --- 34 --- 44 --- 5 --- 15 --- 25 --- 35 --- 45 --- 6 --- 16 --- 26 --- 36 --- 46 --- 7 --- 17 --- 27 --- 37 --- 47 --- 8 --- 18 --- 28 --- 38 --- 48 --- 9 --- 19 --- 29 --- 39 --- 49 --- 10 --- 20 --- 30 --- 40 --- 50 --- ═══════════════════════════════════════════════════════════════════════════════ SELECT CONFERENCE via Cursor keys (Press <Esc> to exit conf info) Choose: 1) Active net - all msg 3) Inactive net - all msg 2) Active net - pub msg only 4) Inactive net - pub msg only 5) Prohibit net access ---> end screen capture Now - as you can see, all you get are conference numbers at this stage of the game. So, be sure you know which conference numbers correspond to which conferences within Mail Manager. In the above example, the SPECIAL conference is conference #3. We moved the flashing pointer down to there, and punched "1" to give the user net status to all messages in that area, and to activate this conference. Here's what the five options do: 1) Active net - all msg: Sets user to be able to receive all messages in the conference, and turns this conference "on" as though the user had seleted it in his own configuration when online. 2) Active net - pub msg only: Sets user to be able to receive only public messages in the conference, and turns this conference "on" as though the user had seleted it in his own configuration when online. 3) Inactive net - all msg: Similar to option 1) but does not turn the conference "on". With this option you give the net user the POTENTIAL to participate in this conference, if he chooses to activate it. 4) Inactive net - pub msg only: Similar to option 2) but does not turn the conference "on". With this option you give the net user the POTENTIAL to participate in this conference, if he chooses to activate it. 5) Prohibit net access: A user given "net status" will only be able to extract messages from, or upload message to, message bases in which you have specifically granted him net access. If you want to deny net status to that conference entirely, hit option "5". (Default, if you do nothing, is to deny net access.) ********************************************************************** * IMPORTANT NOTE: Many established networks, such as FIDONet, * * RBBSNet, and RIME do not permit unauthorized distribution of their * * message bases. ** DO NOT ** grant net access to such conferences * * without first obtaining permission from proper authorities. * ********************************************************************** When you've granted net access to the conferences you'd like, you're done. Hit [Esc] twice to get out of MUSER, and you will be back at the DOS prompt. You just set up "NODE MAIL" for net status to your "SPECIAL" conference. From this point on, all of the dirty work is done on "NODE MAIL"'s end of the line, and you as the host are FINISHED! Just be sure that ole' NODE MAIL can join your "SPECIAL" conference via either RBBS or Mail Manager itself (or you can add NODE MAIL to the conference user file manually), or the whole purpose of all of this will be defeated. NODE MAIL will now be able to extract special "net status" packets from the conferences you've set up for him. He will also be able to upload REP messages to those same conferences, regardless of the name found in the "from" field of the message headers. Also, MAIL MANAGER +PLUS+ will keep track of which messages originally came from NODE MAIL's system, and will not allow him to extract those same messages in subsequent QWK packets, thus preventing annoying duplication of messages. ------------------------------------------------------------------------------ PHASE III: SETTING UP THE NODE ------------------------------------------------------------------------------ You lucky dog you... you get to do all the file conversion! OK - let's just use the names we mentioned above for setting up the host here, to avoid confusion. In this case, here is your scenario: - You are John Doe, who logs onto the host's board and downloads a "net status" packet called "HOST.QWK". - You are networking his "SPECIAL" conference, which is area #3 on his system. - The REP packets that you send up to him will be named "HOST.REP". Now, time to make some assumptions about your own system. Again, let us stress that these are just example names for the purposes of creating a scenario for helping you set this up. - Your board uses the filenames "NODE.QWK" and "NODE.REP" for qwk and rep packets transferred. - The networked "SPECIAL" conference is area #15 on your system. If you are already using some other type of utility, or are not running RBBS-PC, it is UP TO YOU to perform the magic. The following instructions pertain to RBBS-PC, and this net-status beta version of Mail Manager +Plus+. A quick aside - why RBBS sysops might want to use MNET and MMGR+ for node importing/exporting instead of other options: 1) By importing/exporting via an established QWK door, the door can keep track of message pointers. Using external utilities generally means they have to keep their own message pointers, and any message base renumbering that takes place must also renumber these external pointers for proper operation. MMGR+ uses the same user records RBBS does to keep track of message pointers, eliminating the need for any separate updating of pointers. 2) MMGR+ will automatically keep track of which messages came from which host. When extracting a later QWK for export to the host, MMGR+ knows not to extract these messages, thus preventing annoying duplicate messages from being exported. As a result, you don't have to reset your message pointers after uploading a new REP, thus eliminating the possibility of skipping messages that were entered locally just prior to uploading the REP. 3) If you have any conferences set up to support aliases, MMGR+ will extend this support to "netted" messages. Now back to how to set this beast up... The MNET.EXE utility will do all of the QWK -> REP conversion for you. Before we talk about how to use it, we had best lay out your scenario: - When you export messages, you generate HOST.REP which contains any messages you wish to send to the host. You call up the host board, using whatever "net status" name has been established for you on the host board, send up any waiting HOST.REP from your board and download a new HOST.QWK. You then log off the host. Now back at your end, you import any new messages from the host into your system. All the fun part of pulling this off is on your end: 1) You fire up Mail Manager +Plus+ locally using a special name and password that you've configured to handle mail to/from "HOST", and extract NODE.QWK. 2) The host system can't do anything with NODE.QWK, so you use our MNET utility to convert it to HOST.REP. 3) Call up the HOST board, extract and download a new HOST.QWK and upload your HOST.REP reply packet. 4) Convert the HOST.QWK that you received to NODE.REP via MNET. 5) Go back into Mail Manager +Plus+ again using that same special user name, and upload the new messages from the host as NODE.REP. Repeat into infinity. First thing in setting this up is to create a special user name you will use on your system for handling net mail to/from the host. For this example, we'll use the name HOST MAIL. If you do not do this, Mail Manager +Plus+ will not be able to keep track of which messages were imported to your system from the host, and will not be able to prevent these messages from being extracted and sent back to the host as duplicate messages in subsequent QWKs. If you participate in more than one net, you'll need to set up a separate name for each net. You use the new MUSER utility to do this, and the process is nearly identical to that used when setting a user up as a "net status" node caller to your system. The ONLY difference in what you do to set it up is that, instead of telling MUSER that this special user name is a "net node", you should tell MUSER that this name is a "net host". In operation, Mail Manager +Plus+ does not add "net status" information when it extracts a QWK for a "net host" user. Please see the discussion on setting up a host system, above. Now for setting yourself up to use the MNET utility. The MNET command line is like so: MNET <HOSTNAME> <I> <O> hostname = up to 8 characters for what you will be receiving from and sending to your host. Example: "HOST" would mean HOST.QWK and HOST.REP. I = Input. Convert incoming HOST.QWK to NODE.REP. O = Output. Convert outgoing NODE.QWK to HOST.REP. You will need a configuration file for each "HOSTNAME" that you intend to set up with MNET. If your host's QWK's will be named HOST.QWK, you would set up a file named "HOST.CFG", and call MNET like so: MNET HOST I (convert HOST.QWK to NODE.REP) MNET HOST O (convert NODE.QWK to HOST.REP) That's it. Based on all of the examples we have mentioned here, here is an example HOST.CFG file: ---------------------- ;Sample MNET configuration file NODE ; NODE PACKET NAME JOHN DOE ; NODE SYSOP HOST SYSOPNAME ; HOST SYSOP d:\mmgr\plus\ ; NODE PACKET DIRECTORY d:\mmgr\plus\ ; HOST PACKET DIRECTORY Origin: Node BBS (123) 456-7890 ; NODE TAGLINE Origin: Host BBS (098) 765-4321 ; HOST TAGLINE PKZIP [FILE] ; PACK COMMAND LINE PKUNZIP [FILE] ; UNPACK COMMAND LINE ; ALL REMAINING LINES CONSIST OF THREE PARAMETERS, SEPARATED BY COMMAS ; NODE CONF, HOST CONF, PRIVATE ALLOWED (Yes, No, Convert priv to pub) 15, 3, Y ------------------------ That's it. Here's what all of these options mean to MNET: Line 1 = NODE PACKET NAME. (up to 8 characters, NO EXTENSION!) This is whatever your QWK and REP packets are named on your end of the line. The example shown above would mean NODE.REP and NODE.QWK. Line 2 = NODE SYSOP NAME. (Your name as you are known to your users). MNET will convert all messages to and from "SYSOP" to your true name before they go out the door. Line 3 = HOST SYSOP NAME. (The sysop's name of the HOST board). MNET will convert all incoming messages to and from "SYSOP" to the name entered here. Line 4 = NODE PACKET DIRECTORY. (Where YOUR QWK's and REP's are stored). Line 5 = HOST PACKET DIRECTORY. (Where "HOST"'s incoming QWK's and outgoing REP's are stored on your system). Line 6 = NODE TAGLINE. (Tagline to append to outgoing messages) Line 7 = HOST TAGLINE. (Tagline to append to incoming messages) Line 8 = PACK COMMAND LINE. (Archiver of your choice to create *.QWK/REP) Line 9 = UNPACK COMMAND LINE. (Archiver of your choice to extract from *.QWK) Note the use of "[FILE]" in the pack and unpack strings. MNET will replace "[FILE]" with the appropriate file name. All remaining lines = NodeConf#, HostConf#, PrivateHandling NodeConf# = The conference number as it appears on YOUR end. HostConf# = The conference number as it appears on HIS end. PrivateHandling = "Y", "N", or "C". Y = Yes, allow private messages - pass them thru unchanged N = No, ignore private messages - don't even pass them thru C = Convert private messages to public. So, as we stated earlier, "SPECIAL" conference is #3 on the host, and #15 on your end of the line. You want to allow private msgs. Your line would look like: 15, 3, Y Add additional lines for additional conferences. You can run MNET from any directory you choose, but it expects to find any host configuration files (HOST.CFG in our example) in the current directory. That should be about it. Now, for an example batch file <gasp> that would attempt to automate all of this for you. Here's your scenario: 1) You would physically call up your host and transfer any QWK's and/or REP's. We leave it up to *YOU* as for how to automate this end for your particular comm software and commands needed for your host, and have assumed that the batch file you use for this is called MAILRUN.BAT. If you aren't doing this via batch file, you would have to perform these steps manually. 2) Now, you will want to perform the conversion, and ready any packets for "HOST" at the same time. You have already created HOST.CFG for the MNET utility, so now you will need to create a special DORINFOx.DEF file for Mail Manager +Plus+ to operate automatically in local mode. For purposes of illustration: - We'll continue to use the name HOST MAIL. - We will say for the sake of argument that you have already logged onto Mail Manager +Plus+ as "HOST MAIL", and set all of your options the way you want them. - You will be using an unused node number on your system for Mail Manager +Plus+ to do this in local mode. (If you've ever wondered how to log onto Mail Manager in local mode with a different name than is shown for local mode in MAILCFG, this is how you do it.) Let's say you picked node "5" for this. With all of that in mind, you would create a DORINFO5.DEF in your Mail Manager directory that looks like this: NODE BBSNAME ; Whatever your BBS name is. NODESYSOPFIRST ; Your first name NODESYSOPLAST ; Your last name COM0 ; COM0 means local mode 19200 BAUD,N,8,1 ; Baud rate doesn't matter. 0 ; Network type. 0=DOS, 4=DV, 6=NetBIOS HOST ; Your "special" first name. MAIL ; Your "special" last name. ANYTOWN, USA ; Whatever City/State you want to use (doesn't matter) 2 ; Graphics to use (0=none, 1=ascii, 2=ansi) 30 ; Security level for this user. 180 ; # of minutes available for local MMGR session -1 ; Fossil active (doesn't matter... 0 or -1) You would just copy one of your own existing DORINFOx.DEF files here, and edit it accordingly. The comments shown above should NOT be there, of course. Now - assuming (we have to do lots of assuming here...) that your mail manager directory is C:\MAILMGR, you would set your HOST.CFG to point to C:\MAILMGR\NODE5\ for the "node" packet directory. Set the "host" packet directory for wherever your HOST.QWK's will be received. Since this batch file runs MNET from the \MAILMGR directory, HOST.CFG would have to be in the \MAILMGR directory also: Batch file time: c: ; Change to Mail Manager drive, cd\mailmgr ; Change to Mail Manager directory. mailmgr 5 /o ; Run MMGR in automatic Output mode. Create NODE.QWK. mnet host o ; Read HOST.CFG, and convert "NODE.QWK" to "HOST.REP". call mailrun.bat ; Batch file you have written to call your host, upload ; your HOST.REP and download a new HOST.QWK. Use CALL ; so that control is returned to this batch file when ; finished. Otherwise, processing will end here. mnet host i ; Read HOST.CFG, and convert "HOST.QWK" to "NODE.REP". mailmgr 5 /i ; Run MMGR in automatic Input mode. Upload NODE.QWK. And that is it. You may want to embellish this, to delete old QWK or REP files when they are no longer needed, etc., but these are the basic requirements. Whew! That's a lot of work. Wouldn't you rather be a host? ------------------------------------------------------------------------------ FINAL THOUGHTS ------------------------------------------------------------------------------ We know these docs are a bit on the rough side, but we THINK you'll find everything you need here. WE REALLY HOPE THAT THIS MAKES SOME TYPE OF SENSE!!!!!! <g> Any suggestions for improving this document will be GREATFULLY received. Best, Chip Morrow and Doug Wilson The Demented Programming team in Newark, OH P.S. --- Acknowledgements --- The addition of "net status" capability to Mail Manager has been one of the MOST requested featured since day 1. Unfortunately, for a long time, nobody was able to provide any information on what this entailed. Many thanks go out to Marion Royal, who took it upon himself to bird dog this information and provide it to us here at Newark Connections. Thanks, Marion, "this Bud's for you". <grin>